Method and apparatus for transferring files to clients using a peer-to-peer file transfer model and a client-server transfer model

ABSTRACT

A method and apparatus is provided for delivering a content file to a client over a packet-switched network. The method begins by determining a suitable throughput required to deliver the content file to the client. Next, the throughput available in a peer-to-peer network for delivering the content file to the client is determined. The required throughput is compared to the available throughput. If the available throughput is less than the required throughput, the available throughput is supplemented with additional throughput. The content is then delivered to the client over the packet-switched network using the available throughput of the peer-to-peer network and the additional throughput.

STATEMENT OF RELATED APPLICATIONS

This application is a continuation application of U.S. patentapplication Ser. No. 13/084,039, filed Apr. 11, 2011, entitled “Methodand Apparatus for Transferring Files to Clients Using a Peer-to-PeerFile Transfer Model and a Client-Server Transfer Model” which claimspriority from U.S. patent application Ser. No. 11/726,956, filed Mar.23, 2007, now U.S. Pat. No. 7,945,689, entitled “Method and Apparatusfor Transferring Files to Clients Using a Peer-to-Peer File TransferModel and a Client-Server Transfer Model”.

Each of the above referenced applications is hereby incorporated byreference in its entirety.

FIELD OF THE INVENTION

The present invention relates generally to techniques for deliveringcontent to one or more clients over a packet-switched network such asthe Internet, and more particularly to a method and apparatus usingpeer-to-peer networks and content delivery network (CDNs) to delivercontent to clients.

BACKGROUND OF THE INVENTION

The providers of popular, large digital files, such as software, musicor video files, must keep pace with the ever increasing bandwidthdemands for delivering such files. As the popularity of a fileincreases, a larger number of users request the file and more bandwidthis required to deliver the file. With conventional Hypertext TransferProtocol (HTTP) file delivery techniques, for example, the bandwidthrequirements increase linearly with the number of requesting users, andquickly becomes prohibitively expensive.

Accordingly, there is a continuing need to improve the delivery ofcontent to users over communications networks such as the Internet.

SUMMARY OF THE INVENTION

In accordance with the present invention, a method and apparatus isprovided for delivering a content file to a client over apacket-switched network. The method begins by determining a suitablethroughput required to deliver the content file to the client. Next, thethroughput available in a peer-to-peer network for delivering thecontent file to the client is determined. The required throughput iscompared to the available throughput. If the available throughput isless than the required throughput, the available throughput issupplemented with additional throughput. The content is then deliveredto the client over the packet-switched network using the availablethroughput of the peer-to-peer network and the additional throughput.

In accordance with one aspect of the invention, the additionalthroughput may be provided by a backup server that is employed as a peerin the peer-to-peer network on an as-needed basis.

In accordance with another aspect of the invention, the additionalthroughput may be provided by a content delivery network.

In accordance with another aspect of the invention, delivery of thecontent to the client may further include delivering one portion of thecontent file over the peer-to-peer network and a remaining portion ofthe content file over the content delivery network.

In accordance with another aspect of the invention, the peer-to-peernetwork may operate in accordance with a file transfer protocol selectedfrom the group consisting of BitTorrent, Kazaa, eDonkey, Gnutella, andDirect Connect.

In accordance with another aspect of the invention, the backup servermay be configured to function as a seed client.

In accordance with another aspect of the invention, a determination ismade of a delivery method to be employed in connection with the contentfile.

In accordance with another aspect of the invention, the delivery methodis selected from the group consisting of a streaming media method or afile downloading method.

In accordance with another aspect of the invention, a method is providedfor delivering a content file to a client over a packetswitched-network. The method begins by delivering at least one portionof the content file over the packet-switched network using apeer-to-peer file transfer model. The method continues by delivering aremaining portion of the content file over the packet-switched networkusing a client-server file transfer model.

In accordance with another aspect of the invention, a method is providedfor receiving a content file over a packet-switched network. The methodbegins by receiving at least one portion of the content file over thepacket-switched network using a peer-to-peer file transfer model. Themethod continues by receiving a remaining portion of the content fileover the packet-switched network using a client-server file transfermodel.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a high level block diagram of one example of a peer-to-peerfile sharing network

FIG. 2 depicts a high-level block diagram of one example of CDN network.

FIG. 3 shows a hybrid network that employs both peer-to-peer and contentdelivery models.

FIG. 4 is a flowchart showing one example of a process that may beemployed to determine the best use of the resources of the hybridnetwork depicted in FIG. 3 to deliver a content file to a client.

FIG. 5 is a flowchart showing in greater detail the step in theflowchart of FIG. 4 in which the available throughput of thepeer-to-peer network is determined when augmented by either a backuppeer server or with the resources of a content delivery network.

DETAILED DESCRIPTION

As described in more detail below, the present invention can employ botha client-server or content delivery network model and a peer-to-peerfile transfer model to transfer content files from a content originatorto multiple clients. The content file may be include, withoutlimitation, data, video, audio, html pages and associated embeddedobjects, and any combinations thereof. In particular, the invention candynamically choose which download model is most appropriate at any giventime for any particular content file that a client wishes to download.Before describing various features of the invention in greater detail, adescription of both a peer-to-peer network and a content deliverynetwork will be presented. For clarity of discussion, the two modelswith be discussed separately with reference to FIGS. 1 and 2.

The most common method by which files are transferred on the Internet isthe client-server model. A central server sends the entire file to eachclient that requests it—both http and ftp operate in this manner. Theclients only communicate with the server and not with each other. Themain advantage of the client-server model is its simplicity—a user logsonto a server and initiates the download process. Additionally, filesare usually available for long periods of time as the servers tend to bededicated to the task of serving, and are always on and connected to theInternet. Another important advantage of the client-server model is thatthe Quality of Service provided to the client, in terms of datathroughput and latency, is largely controlled by the server and can beeffectively guaranteed. In this context, throughput refers to the amountof actual user data (i.e., payload) transmitted per unit time withoutthe overhead of protocol information such as start and stop bits, TCP/IPoverhead, HTTP headers, and the like. Throughput can vary with time anddepends on a variety of factors such as bandwidth, latency (i.e., theminimum time needed to send the smallest possible amount of data),payload size, packet size, network load, the number of hops required,and so on.

However, the client-server model has significant problems with filesthat are large and/or very popular such as newly released content. Inparticular, a great deal of bandwidth and server resources must bededicated to distributing each file, since the server must transmit theentire file to each client. As a result, the server is burdened with theentirety of the content delivery costs. Because of these problemscontent providers sometimes employ so-called content delivery serviceproviders (CDSPs) to efficiently deliver the content on their behalf.The CDSP operates a Content Delivery Network (CDN), which is a networkof geographically distributed content delivery nodes that are arrangedfor efficient delivery of content on behalf of third party contentproviders. A request from a requesting end user for a given content fileis directed to a “best” replica, where “best” usually means that theitem is served to the client quickly compared to the time it would taketo fetch it from the content provider origin server. A content deliverynetwork comprises a set of content delivery servers (CDSs) dispersedacross the Internet, as well as a domain name server (DNS)infrastructure, which is used to route user requests to the nearest CDS.The DNS requests sent from the user browser need to be directed to theDNS of the CDSP. One technique is for the CDSP to “takeover” the DNSfunctionality of the origin site so as to become the “authoritative DNS”for the origin site. CDNs do not eliminate the problems inherent in theclient-server model. Rather, they simply transfer the burden ofdownloading files from the originating content provider to a thirdparty.

A number of techniques have been proposed for reducing the bandwidthdemands of file delivery using a client-server model. For example, in apeer-to-peer content sharing model, sometimes referred to as“cooperative distribution,” one or more users that have previouslydownloaded a file can share the file with other users. A cooperativedistribution model allows a server to deliver large files in a reliablemanner that scales with the number of requesting users. Among otherbenefits, cooperative distribution models exploit the underutilizedupstream bandwidth of existing users. Current Examples of peer-to-peernetworks include systems such as BitTorrent, Kazaa, eDonkey, Gnutella,Direct Connect and the like.

In the BitTorrent file distribution system, for example, content filesare divided into blocks and users attempt to find peers that togethercontain all of the blocks. When multiple users are downloading the samefile at the same time, the various users upload blocks of the file toeach other. In other words, a BitTorrent user trades blocks of a filethat the user has with other required blocks that other users have untilthe complete file is obtained. The key philosophy of BitTorrent is thatusers should upload (transmit outbound) at the same time they aredownloading (receiving inbound). In this manner, network bandwidth isutilized as efficiently as possible and the cost of uploading a file isredistributed to the users of the file and the cost of hosting a popularfile is more affordable. BitTorrent is designed to work better as thenumber of people interested in a particular file increases, in contrastto other file transfer protocols where more users tend to bog the systemdown.

Peer-to-peer content sharing models can reduce the costs associated withdelivering content to the client because they leverage the availableupstream bandwidth of the clients. In this way the bandwidth costs thatwould otherwise be associated with a centralized download server aregreatly reduced. Unfortunately, the Quality of Service provided to theclient cannot be guaranteed because it is not under the complete controlof the content deliverer, but rather is highly dependent on the numberof clients actively downloading the content and the uplink speeds ofthose clients.

Thus, the present inventor has recognized that neither the client servermodel, as represented by a content delivery network, for example, norpeer-to-peer models are completely satisfactory for the purpose ofdelivering content to clients. The methods, systems and techniquesdetailed below better utilize both file sharing techniques.

FIG. 1 shows a high level block diagram of one example of a peer-to-peerfile sharing network in which individual nodes communicate over a packetswitched network 180 such as the Internet. Although the methodsdescribed herein are generally applicable to all such networkssupporting file sharing by client peers, the BitTorrent network protocolis used in the following description for illustrative purposes. However,the invention is equally applicable to other peer-to-peer networks, bothdecentralized and centralized, using any suitable protocol suchGnutella, eDonkey, KaZaA, Gnutella, Direct Connect and the like.

In FIG. 1, one or more servers, such as servers 111 and 112, serve asdepositories of a file (TFILE) 124 that contains metadata concerning acontent file that is to be shared among client nodes, such as clients101-104. In the context of BitTorrent, the file 124 is often referred toas a torrent file 124. The torrent file 124 may contain information suchas the URL of the tracker server (described below), suggested names forthe individual blocks of the content file to be delivered, the blocklength used, and a hash code for each block, which clients can use toverify the integrity of the data they receive. Users of the clients101-104 must first download the torrent file 124 before accessing thedesired content file. The appropriate torrent file 124 may be located bythe user in any conventional manner. For example, the user may alreadyknow the web addresses of one or more of the servers 111 and 112 so thatthey can contact them directly to download the torrent file 124, or theuser may be linked to the torrent file 124 through a web page, or theymay otherwise find the torrent file 124 by searching for it using anInternet search engine.

Each of the clients 101-104 is configured with a client version of afile sharing program (CPRG) 130. The client program 130 is used todownload and open the torrent file 124. The client program 130 displaysfor the user one or more tracker servers, such as tracker servers 141and 142, which coordinate the action of all the clients or peers. Thetracker server only manages connections and does not have any knowledgeof the contents of the files being distributed, and therefore a largenumber of users can be supported with a relatively limited trackerbandwidth. The tracker server maintains lists of clients currentlyparticipating in the file sharing process for the desired content file.The user then selects one of the identified tracker servers to contactin order to procure a copy of the content file. The client program 130then establishes communication with the selected tracker server. Thetracker server sends the client program 130 a list of other peerscurrently downloading blocks of the content file that the clients101-104 desire.

As an example, if users of clients 101 and 102 select tracker server141, their respective client programs 130 contact and communicate withthe tracker program 150 of the tracker server 141. The tracker program150 then sends a network list back to each of the connecting clients 101and 102. Included in the network list is contact information for atleast one “seed” client, such as client 104, which has a full copy ofthe content file that the clients 101 and 102 wish to procure, as wellas contact information for clients such as clients 101 and 102 that haverecently contacted the tracker server 141 regarding the content file.The client programs 130 of clients 101 and 102 then use the informationin the provided network list to establish peer-to-peer communicationswith the seed client 104 and with one another in order to download thecontent file. The client connects to those peers to obtain the variousblocks of the content file. Such a group of peers connected to eachother to share a torrent is often called a swarm. If the swarm containsonly the initial seeder, the client connects directly to it and beginsto request blocks. As peers enter the swarm, they begin to trade blockswith one another, instead of downloading directly from the seed.

Initially, the seed client 104 may be the only client in thepeer-to-peer network that has any of the blocks available for delivery.When a block is successfully downloaded to one of the clients, however,the client program 130 of that client announces to other clients that itnow has a block available for downloading. As more clients join thepeer-to-peer network along with the clients 101 and 102, this willfurther serve to speed up the distribution of the content file to allpeer-to-peer network clients as they participate in the swarm download.Eventually, all of the blocks of the content file may be availablewithin the peer-to-peer network from peers other than the seed client104. At that time, the seed client 104 may disconnect itself from thepeer-to-peer network.

Before announcing the availability of an assembled block that has beendownloaded, the client program 130 will generally first verify that theassembled block is good. It does this, for example, by calculating ahash value for the assembled block and comparing the calculated hashvalue against a known hash value provided, for example, in the Torrentfile 124. If the two hash values match, then the block is determined tobe good. In this case, the other peer-to-peer clients are notified bythe client program 130 of the assembled block's availability fordownloading. On the other hand, if the two hash values do not match,then the block is determined to be corrupted. In this case, theindividual blocks for that assembled block are discarded and requestedagain from the same or different sources (i.e., other clients on thepeer-to-peer network). As clients successfully download all blocks ofthe content file, they may disconnect from the peer-to-peer network. Atthe same time, other clients may be joining the peer-to-peer network todownload the content file from remaining peers in the peer-to-peernetwork. In order to be notified of such newly joining clients, as wellas to maintain its own contact information in the network list, it isuseful for a client already participating in a swarm download toperiodically re-connect to the tracker server and obtain an updatednetwork list.

FIG. 2 depicts a high-level block diagram of one example of CDN network.In FIGS. 1 and 2, as well as the figures that follow, like elementsdenote are denoted by like reference numerals. The network 100 comprisesclients 101-104, as in FIG. 1, at least one content delivery network(CDN) 170, which is operated by a content delivery service provider(CDSP), a packet switched network 180 (e.g., the Internet), and anoriginating content provider network 120.

Clients 101-104 are employed by users requesting content. The CDSPprovides connectivity between clients 101-104 and the content providernetwork 120 via the CDN 170 and the packet-switched network 180.Although only one CDN 170 is illustratively shown in FIG. 1, one skilledin the art will appreciate that a plurality of CDNs 170 may be connectedto the packet-switched network 180 to provide content to client computerdevices.

The content provider network 120 comprises a plurality of content(origin) servers 126 ₁, through 126 _(q) (collectively content servers126) and an originating domain name server (DNS) 128. In an instancewhere there are multiple content servers 126, as illustratively shown inFIG. 2, a router or switch 122 may be utilized to route information toand from the content server 126 associated with user requested content.

The content delivery network (CDN) 170 comprises a set of cache servers110 ₁ through 110 _(p) (also referred to as “Content Delivery Servers”(CDSs), collectively CDSs 110) on the edge of the network 170, as wellas a domain name server (DNS) infrastructure 108, which is used to routeuser requests to the nearest CDS 110. In operation, DNS requests sentfrom the clients 101-104 are directed to the DNS 108 of the CDSP 170.This may be accomplished, for example, by allowing the CDSP 170 to“takeover” the DNS functionality of the originating content providernetwork 120 so as to become the “authoritative DNS” for the originatingsite.

Content delivery service providers (CDSP) enable distribution of contentfrom the originating sites (i.e., content servers 126) to the CDSservers 110 on the edge of the network 180, which in turn delivercontent to the clients 101-104. The distribution mechanism may be basedboth on push technologies such as multicasting the data to all the edgeservers through terrestrial or satellite links or pull technologies suchas those used by proxies. The goal is to decrease the latency of useraccess to the content files by delivering the files from a CDS edgeserver closest to the user.

As previously mentioned, peer-to-peer networks and content deliverynetworks both have their advantages and disadvantages. For instance,CDNs require a great deal of bandwidth and server resources since theserver must transmit the entire file to each client. As a result, theserver is burdened with the entirety of the delivery costs of thecontent. CDNs, however, can best control the Quality of Service that isprovided to the client. Peer-to-peer networks, on the other hand, reducethe burden placed on a centralized server by leveraging the availableupstream bandwidth of the clients, but with less control over theQuality of Service that is delivered to the client.

The present invention uses a combination of a content delivery networkmodel and a peer-to-peer network model to transfer files from a contentoriginator to multiple clients to overcome the aforementioned problemsand limitations. A number of questions should be answered to determinethe optimal combination of the two network models to be used. Inparticular, it should first be determined how quickly the file needs tobe sent to the client. It then needs to be determined how the data canbe sent at the required speed with minimal cost.

In determining how quickly the file needs to be sent to the client aprimary consideration is the type of medium that the client wishes toreceive. For instance, if the content file is to be delivered inreal-time (e.g., as a streaming media file) a higher throughput (e.g.,bit rate) will be required than if the file is simply to be downloadedto the client. Once the required throughput is determined, it iscompared to the throughput of the peer-to-peer network. If thethroughput of the peer-to-peer network is sufficient, then this model isused to deliver the content file. On the other hand, if the throughputof the peer-to-peer network is insufficient, then the peer-to-peernetwork may still be used to deliver the file by supplementing itsthroughput by other techniques.

One way to supplement or augment the throughput of a peer-to-peernetwork is to employ what may be referred to as a backup peer server.The backup peer server, which contains a copy of the content file to bedelivered, can be used as an additional peer to increase the throughputof the swarm. The backup peer server will be a seed client if itcontains a complete copy of the content file to be delivered. Theresources of the backup peer server need only be invoked when necessaryto increase the throughput of the peer-to-peer network to deliver aparticular content file.

Another way to supplement or augment the throughput of the peer-to-peernetwork is by using a content delivery network to deliver portions ofthe content files to the client. For instance, a portion of a contentfile may be reserved for delivery by the content delivery network. Thereserved portion of the file may be some fraction (e.g., half) of thefile or a certain number of blocks that would otherwise need to bedelivered over the peer-to-peer network.

FIG. 3 shows the peer-to-peer and content delivery networks depicted inFIGS. 1 and 2, respectively, along with a state server 160 that is usedto coordinate the activities of the two networks. The state server 160monitors the throughput requirements of the content file and thethroughput capacity of the peer-to-peer networks and invokes theresources of the content delivery network as necessary to deliver thecontent file in accordance with the file's throughput requirements. Alsoshown is a backup peer server 190 which can provide additional resourcesto the peer-to-peer network on an as-needed basis.

The state server 160 will typically be continuously monitoring thenetworks depicted in FIG. 3. Since individual peer clients may join/dropat will, the available throughput in the network will be constantlychanging. In fact, the throughput of the various blocks of a file willin general differ from block to block. For instance, if two peer clientshave all the blocks of a given file (say blocks 1-10, for example) twoother peer clients have blocks 1 and 2, and yet two different peerclients have blocks 3 and 5, blocks 1, 2, 3 and 4 will have the highestavailable (6xclient-speed), while pieces 5 to 10 will have lowerthrougputs (2xclient-speed). This example assumes, of course, that theupload rates are the same for all the peer clients. For this reason thestate server 160 should continuously monitor the throughput rates sincethey may dynamically vary in this manner.

FIG. 4 is a flowchart showing one example of a process that may beemployed to determine the best use of network resources to deliver acontent file to a client. The process begins in step 205 when thepeer-to-peer network calculates the throughput requirements of a filethat a client has requested for delivery. The calculation may beperformed in accordance with any well-known technique by the trackerserver or any other appropriate entity in the peer-to-peer network. Thethroughput requirement will in large part depend on whether the contentis to be delivered in real-time or downloaded for subsequent use.Similarly, in step 210 the throughput of the peer-to-peer network isdetermined at the time the file is to be delivered. The throughput ofthe peer-to-peer network will depend on a number of things, most notablythe sum of the available uplink bandwidth of the individual clients inthe swarm. The required and available throughputs are compared atdecision step 215. If the available throughput is about equal to orgreater than the required throughput, then in step 220 the content fileis downloaded using the peer-to-peer network exclusively. On the otherhand, if at decision step 215 it is determined that the availablethroughput of the peer-to-peer network is not sufficient to deliver thefile, then the process continues at step 225 in which the availablethroughput of the peer-to-peer network is determined when augmented byeither a backup peer server or with the resources of a content deliverynetwork. In decision step 230 the throughput of the augmentedpeer-to-peer network is compared to the required throughput. If theavailable throughput of the peer-to-peer network as augmented in thismanner is sufficient, then the content file is delivered using theaugmented peer-to-peer network in step 235. If the throughput of theaugmented peer-to-peer network is still not sufficient to deliver thecontent file, then in step 240 the content delivery network isexclusively used to deliver the file.

FIG. 5 is a flowchart showing in greater detail step 225 of FIG. 4, inwhich the available throughput of the peer-to-peer network is determinedwhen augmented by either a backup peer server or with the resources of acontent delivery network. In step 305 the available throughput of thepeer-to-peer network is calculated when augmented with a backup peerserver. The required and available throughputs are compared at decisionstep 310. If the available throughput is about equal to or greater thanthe required throughput, then in step 315 the content file is downloadedusing the peer-to-peer network augmented with the backup peer server. Onthe other hand, if at decision step 310 it is determined that theavailable throughput of the peer-to-peer network augmented with thebackup peer server is not sufficient to deliver the file, then theprocess continues at step 320 in which the available throughput of thepeer-to-peer network is determined when augmented by with the resourcesof a content delivery network.

The content file to be delivered to clients in accordance with thetechniques described above may be any type of file to be downloaded,streamed, or delivered over a communications network by any other means.Such files may include, without limitation, application programs andother executable files, data files, audio, video and multimedia files,operating system components, drivers, updates and the like. For example,in some embodiments the files that are downloaded may be softwareproducts associated with consumer electronic devices (e.g., personalcomputers, personal digital assistants (PDAs), video cameras, digitalcameras, MP3 players), which software products are made available by themanufacturer or vendor of the consumer electronic devices.

The files or software products to be delivered to the client in somecases may be delivered in accordance with an associated service. Forexample, the client may contact a web site that provides a customer of aconsumer electronic device with product updates, service updates,warranty information or otherwise manages a suite of services availableto the customer. In another example, the files to be delivered may becontent files (e.g., video) that a client uploads to a central server tobe synchronized with other consumer electronic devices, stored and/orshared with other clients. Such content files may be delivered to otherclients or consumer electronic devices in accordance with the techniquesdescribed herein. The service may also provide ancillary services to thecustomer, such as allowing the customer to register multiple consumerelectronic devices, perform service authentication for each device andmanage each of the devices. The consumer may also use the service tocreate a profile for managing the devices and synchronize contentbetween and among them using the techniques described herein.

1. A method for delivering a content file to a client over a packetswitched-network, comprising: in a server: determining a firstthroughput required to deliver said content file to said client and asecond throughput available in a peer-to-peer network for deliveringsaid content file to said client; supplementing said second throughputavailable in said peer-to-peer network with a third throughput providedby a content delivery network, when said second throughput available insaid peer-to-peer network is less than said first throughput required todeliver said content file to said client; and delivering said contentfile to said client over said packet-switched network using acombination of said second throughput available in said peer-to-peernetwork and said third throughput provided by said content deliverynetwork.
 2. The method of claim 1, further comprising supplementing saidsecond throughput available in said peer-to-peer network with a fourththroughput provided by a backup peer server employed as a peer in saidpeer-to-peer network on an as-needed basis.
 3. The method of claim 2,wherein said backup peer server is configured to function as a seedclient.
 4. The method of claim 1, further comprising determining saidfirst throughput required to deliver said content file based on adelivery method to be employed for delivering said content file to saidclient.
 5. The method of claim 4, wherein said delivery method to beemployed for delivering said content file to said client comprises oneof: a streaming media method or a file downloading method.
 6. The methodof claim 1, further comprising delivering a first portion of saidcontent file over said peer-to-peer network and a second portion of saidcontent file over said content delivery network.
 7. The method of claim1, wherein said peer-to-peer network operates based on a file transferprotocol, wherein said file transfer protocol comprises one of:BitTorrent, Kazaa, eDonkey, Gnutella, and Direct Connect.
 8. A methodfor delivering a content file to a client over a packet-switchednetwork, comprising: in a server: determining a first throughputrequired to deliver said content file to said client and a secondthroughput available in a peer-to-peer network for delivering saidcontent file to said client; supplementing said second throughputavailable in said peer-to-peer network with a third throughput providedby a backup peer server, when said second throughput available in saidpeer-to-peer network is less than said first throughput required todeliver said content file to said client; supplementing said secondthroughput available in said peer-to-peer network with a fourththroughput provided by a content delivery network, when a combination ofsaid second throughput available in said peer-to-peer network and saidthird throughput provided by said backup peer server is less than saidfirst throughput required to deliver said content file to said client;and delivering said content file to said client over saidpacket-switched network using a combination of said second throughputavailable in said peer-to-peer network, said third throughput providedby said backup peer server, and said fourth throughput provided by saidcontent delivery network.
 9. The method of claim 8, wherein said contentdelivery network employs a client-server protocol and is configured suchthat a central server delivers said content file to each client thatrequests said content file, wherein said client is configured to onlycommunicate with said central server.
 10. The method of claim 8, furthercomprising delivering a first portion of said content file over saidpeer-to-peer network, a second portion of said content file over saidbackup peer server, and a remaining portion of said content file oversaid content delivery network.
 11. The method of claim 8, wherein saidpeer-to-peer network operates based on a file transfer protocol, whereinsaid file transfer protocol comprises one of: BitTorrent, Kazaa,eDonkey, Gnutella, and Direct Connect.
 12. The method of claim 8,wherein said backup peer server is configured to function as a seedclient.
 13. The method of claim 8, further comprising determining saidfirst throughput based on a delivery method to be employed fordelivering said content file to said client.
 14. The method of claim 13,wherein said delivery method comprises one of: a streaming media methodor a file downloading method.
 15. The method of claim 8, furthercomprising monitoring said first throughput required to deliver saidcontent file to said client, said second throughput available in saidpeer-to-peer network, said third throughput provided by said backup peerserver, and said fourth throughput provided by said content deliverynetwork.
 16. A method for receiving a content file over apacket-switched network, comprising: in a client communicably coupled toa server: receiving said content file from said server over saidpacket-switched network using a first throughput available in saidpeer-to-peer network when said first throughput available in saidpeer-to-peer network is at least equal to or more than a secondthroughput required to deliver said content file to said client; andreceiving said content file from said server over said packet-switchednetwork using said first throughput available in said peer-to-peernetwork supplemented with a third throughput when said first throughputavailable in said peer-to-peer network is less than said secondthroughput required to deliver said content file to said client, whereinsaid third throughput is provided by a content delivery network.
 17. Themethod of claim 16, further comprising: receiving a first portion ofsaid content file from said server using said peer-to-peer network; andreceiving a remaining portion of said content file from said serverusing said content delivery network.
 18. The method of claim 16, furthercomprising receiving said content file from said server over saidpacket-switched network using said first throughput available in saidpeer-to-peer network further supplemented with a fourth throughput whensaid first throughput supplemented with said third throughput is lessthan said second throughput required to deliver said content file tosaid client, wherein said fourth throughput is provided by a backup peerserver.
 19. The method of claim 18, further comprising: receiving afirst portion of said content file from said server using saidpeer-to-peer network; receiving a second portion of said content filefrom said server using said content delivery network; and receiving aremaining portion of said content file from said server using saidbackup peer server.
 20. The method of claim 16, wherein said contentfile comprises one or more of: an application program, a data file, anaudio file, a video file, a multimedia file, an operating systemcomponent, a software driver, a software update, and a software productassociated with a consumer electronic device.